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A  Session  With  TINKER: 

Interleaving  Program  Testing  With  Program  Design 


Henry  Ueberman  and  Carl  Hewitt 

Artificial  Intelligence  Laboratory 
and  Laboratory  for  Computer  Science 
Massachusetts  Institute  of  Technology 

Abstract 

Tinker  is  an  experimental  interactive  programming  system  which  integrates 
program  testing  with  program  design.  New  procedures  are  created  by 
working  out  the  steps  of  the  procedure  in  concrete  situations.  Tinker 
displays  the  results  of  each  step  as  it  is  performed,  and  constructs  a 
procedure  for  the  general  case  from  sample  calculations.  The  user 
communicates  with  Tinker  mostly  by  selecting  opeations  from  menus  on  an 
interactive  graphic  display  rather  than  by  typing  commands.  This  paper 
presents  a  demonstration  of  our  current  implementation  of  Tinker. 


I.  Introduction 

Tinker  is  our  first  attempt  at  building  an  experimental  programming  environment  for 
Lisp  which  explores  two  new  directions  in  programming  methodology; 

Programs  arc  rested  with  examples  as  they  are  being  written:  In  conventional  systems, 
the  user  writes  a  complete  program,  then  tests  it  as  a  whole.  In  Tinker,  new 
functions  are  defined  by  supplying  examples,  and  working  out  the  steps  of  the 
procedure  on  examples.  As  each  step  of  the  program  is  introduced,  the  effect  of  that 
step  on  an  example  is  displayed  immediately.  Tinker  remembers  the  steps  and 
constructs  a  procedure  for  the  general  case.  Program  writing  and  program  testing 
happen  simultaneously. 

Menu  selection  can  replace  much  typing  in  constructing  programs:  Instead  of  specif)  ing 
operations  and  operands  by  typing,  the  system  displays  on  the  screen  a  menu  of 
available  choices  whenever  possible,  and  the  user  simply  points  to  one  to  select  it. 
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The  user  doesn’t  have  to  remember  or  look  up  in  a  manual  what  commands  are 
available  or  what  the  syntax  of  the  language  is.  We  are  experimenting  with  Tinker 
to  see  to  what  extent  menu  selection  can  replace  typed  commands  in  designing  and 
debugging  programs. 

We  chose  the  name  Tinker  to  suggest  the  process  of  building  or  fixing  something  in 
small  steps,  incrementally  making  a  small  change,  seeing  what  happens,  then  making 
another  change. 

In  contrast  to  previous  research  labelled  as  programming  by  example ;  Tinker  doesn't 
attempt  to  try  to  guess  the  definition  of  the  procedure  from  simply  a  statement  of 
what  values  the  function  returns  for  given  arguments.  Instead,  we  must  explicitly 
demonstrate  the  steps  which  the  procedure  must  take  to  compute  the  value. 
Guessing  the  procedure  definition  from  input-output  histories  is  a  much  harder 
problem.  It  is  an  automatic  programming  task  which  is  currently  beyond  the  state 
of  the  art  for  non-trivial  examples.  Tinker’s  contribution  lies  in  inregrating  the  use  of 
examples  with  program  construction. 

Rather  than  describe  the  capabilities  of  Tinker  in  the  abstract,  we  feel  that  a  good 
way  to  convey  our  ideas  about  programming  methodology  is  to  show  Tinker  in 
action.  The  body  of  this  paper  will  consist  of  a  demonstration  of  Tinker,  presenting 
it  to  the  reader  as  we  would  to  a  new  user  of  the  system.  The  illustrations  depict 
what  appears  on  the  user's  display  screen.  We  will  explain  features  of  Tinker  as 
they  are  encountered  in  the  demonstration. 

Our  session  with  Tinker  will  consist  of  three  parts,  starting  out  very  simply  and 
working  up  toward  more  complicated  tasks.  The  first  part  will  discuss  Tinker’s  user 
interface,  and  show  how  to  build  up  and  evaluate  Lisp  expressions  using  Tinker. 
The  second  will  show  how  to  introduce  new  functions  into  Tinker,  illustrating  the 
role  of  examples.  The  third  part  will  present  a  more  realistic  scenario,  one  which 
would  be  plausible  for  an  experienced  user.  This  will  show  how  to  define  functions 
with  conditionals  through  the  use  of  multiple  examples,  and  recursive  functions  using 
partially  specified  definitions. 


2.  Getting  started 

The  first  illustration  shows  what  Tinker  looks  like  when  it's  first  started.  The  screen 
starts  out  with  three  windows. 
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The  large  window  in  the  center  of  the  screen  is  the  snapshot  window.  The  snapshot 
window  shows  the  current  state  of  the  computatioa  Whenever  we  introduce  a  new 
object  or  piece  of  program  text,  it  will  appear  in  the  snapshot  window.  The 
snapshot  window  always  contains  a  partial  definition  of  the  body  of  some  function. 
(Initially,  we're  defining  a  special  function  called  HISTORY,  which  contains  top  level 
evaluations.)  Later,  when  we  define  a  new  function,  the  name  of  the  function  will 
appear  in  the  label  of  the  snapshot  window,  and  we  will  construct  a  definition  for  it 
in  the  snapshot  window. 

At  the  top  of  the  screen  is  the  Tinker  Edit  menu.  This  shows  the  list  of  available 
operations  at  the  top  level  of  Tinker.  These  operations  edit  the  contents  of  the 
snapshot  window.  They  may  create,  delete,  move  or  modify  objects  in  the  snapshot 
window.  We'll  explain  what  each  editing  operation  does  as  we  go  along. 

We  can  select  an  item  from  the  menu  by  pointing  to  its  name  and  pressing  a  button. 
Tinker  runs  on  the  MIT  Lisp  Machine,  a  personal  computer  equipped  with  a  mouse, 
a  pointing  device.  The  current  position  of  the  mouse  is  indicated  on  the  screen  by 
an  A.  When  the  position  of  the  mouse  touches  the  name  of  an  operation,  the  name 
is  highlighted  on  the  screen. 

The  window  at  the  bottom  of  the  screen  is  the  editor  window.  Occasionally,  linker 
will  ask  the  user  to  type  something,  such  as  names  for  functions,  or  code  to  be 
executed.  F.verything  typed  on  the  keyboard  goes  into  the  editor  window. 
Informative  messages  [like  Welcome  to  Tinker /)  and  error  messages  also  appear  in  the 
editor  window.  The  editor  window  is  connected  to  Zwei,  a  sophisticated  real-time 
display  text  editor.  This  gives  the  user  access  to  a  wide  range  of  editing  operations 
whenever  anything  is  typed.  The  editing  operations  include  motion  across  characters, 
words,  sentences,  and  expressions;  search;  cut  and  paste;  expansion  of  abbreviations; 
and  many  more.  This  is  in  contrast  to  many  systems  which  only  allow  a  few  trivial 
editing  operations  when  typing  input,  and  require  the  user  to  use  a  separate  editor 
program  for  more  extensive  changes. 


3._\V h en  Tin ker  evaluates  some  code  it  remembers  both  the  value  and  the  code 

We  will  first  show  how  to  use  Tinker  as  a  kind  of  desk  calculator  for  Lisp,  building 
up  Lisp  expressions  and  evaluating  them.  Whenever  Tinker  evaluates  an  expression,  it 
reman  hers  the  code  that  produced  that  value.  Whenever  that  value  is  used  as  an 
ingredient  in  a  subsequent  computation,  the  code  corresponding  to  the  value  is 
carried  along.  This  allows  us  to  incrementally  build  up  complicated  expressions. 
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Since  we  get  to  see  all  the  intermediate  results  along  the  way,  we  can  immediately 
verify  the  accuracy  of  each  step  before  proceeding  to  the  next 

One  way  of  introducing  new'  expressions  to  Tinker  is  by  typing.  Tinker  provides  two 
operations  for  introducing  something  new  into  the  snapshot  window  by  typing.  The 
TYPEIN  and  EVAL  operation  is  like  the  READ- EVAL- PRINT  loop  of  Lisp.  It  reads  a  Lisp 
expression  in  the  editor  window  (prompting  with  Type  something  to  evaluate:),  and 
calls  EVAL  on  it.  TYPEIN,  but  DON'T  EVAL  is  similar,  but  doesn't  evaluate  the 
expression.  It  just  reads  an  expression  and  puts  it  in  the  snapshot  window. 

The  first  thing  we  do  is  select  TYPEIN  and  EVAL,  and  type  in  the  code  (LIST  1  2  3) 
in  the  editor  window.  This  evaluates  to  the  list  (1  2  3).  In  the  snapshot  window 
appears  a  message  telling  us  that  the  value  (12  3)  was  produced  by  the  code  (LIST 
l  2  3). 
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_ Defining  (HISTORY): _ 

Example:  (1  2  3),  Code:  (LIST  I  2  3) 


Type  something  To  evaluate: 
(I.ISTJ  2  3) 


Ed »  tor  Window 


Figure  2.  Selecting  the  menu  operation  "TYPEIN  and  EVAL". 

(In  this  case,  the  code  is  always  going  to  evaluate  to  the  same  value,  but  in  general 
the  code  might  have  variables,  and  the  value  shown  may  only  be  an  example  of  what 
the  code  could  evaluate  to.) 
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To  show  what  happens  when  we  make  further  use  of  the  value  (1  2  3),  let’s  try 
reversing  the  list.  We  select  the  operation  call  a  function,  and  Tinker  asks  us  for 
the  name  of  the  function  in  the  editor  window.  We  type  in  REVERSE. 

t)  c  r  ini  nij  (HISTORY): 
tx amp  I  o :  (1  2  3 ) ,  Cod  e :  (IIS Tl?  3) 

Code:  (RLVlRSt  ) 
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Tinker  could  warn  us  right  away,  and  we  could  fix  it  immediately.  In  conventional 
systems,  the  bug  would  go  undetected  until  much  later. 

What  appears  now  on  the  screen  is  a  partial  description  of  some  code,  a  cal!  to 
REVERSE.  It  isn't  complete  yet,  because  we  haven’t  filled  in  the  arguments  to 
REVERSE,  and  evaluated  it. 

Next,  we  select  Fill  in  an  ARGUMENT.  Selecting  the  list  (12  3)  chooses  it  as  the 
argument  to  REVERSE,  moving  the  list  inside  the  call  to  REVERSE.  Tinker 
automatically  makes  this  selection  for  us,  rather  than  stopping  to  ask,  since  there  was 
only  one  piece  of  code  that  needed  arguments,  and  only  one  object  on  the  screen 
that  could  possibly  be  an  argument  to  REVERSE. 


Oefinintj  (HISTORY ) : 

Code: ’’(lUVIRSt  ( QUO  1  (  (  fTTjjj 


"Example:  (1  2  3).  Corte:  H.IST  1  2  3)"  | 
REVERSE 

Since  there  w.ic  only  one  rhnicp,  I  aesumpd: 
"Code:  (REVERSE)" 


Sim  p  IhoiP  w,u  only  mu*  tlinirp,  I  assumed: 

F  r)  r  f.  <>r  I  I I  r  >w  . 

Figure  4.  Selecting  the  menu  operation  "Fill  in  an  ARGUMENT". 
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Tinker  has  a  policy  of  bothering  the  user  as  little  as  possible;  if  it  can  determine 
that  there's  only  one  reasonable  choice  to  be  made,  it  goes  ahead  and  makes  the 
choice.  (The  choice  can  always  be  retracted,  of  course,  if  it  had  any  unwanted 
consequences.)  Tinker  informs  us  of  this  in  the  editor  window  by  saying  Since  there 

was  only  one  choice,  I  assumed:  _  If  there  were  more  than  one  possibility, 

Tinker  would  ask  us  which  one  we  wanted.  We  shall  see  this  later.  Automatically 
making  the  obvious  choice  in  the  current  context  is  very  helpful,  especially  to 
experienced  programmers  who  find  that  this  speeds  up  interaction  with  the  system. 
This  automatic  choice  feature  can  be  disabled  for  naive  users,  or  those  who  don't 
find  it  to  their  taste. 

Now  that  we've  filled  in  all  the  arguments,  we  choose  EVALUATE  something,  to  find 
out  the  value  of  the  call  to  REVERSE.  (Tinker  could  be  made  to  realize  that  since 
REVERSE  takes  only  one  argument,  the  code  could  be  evaluated  as  soon  its  that 
argument  is  filled  in.)  This  produces  the  list  (3  2  1)  from  (1  2  3). 

_  _  Her  i  n  i  nij  ( II  i  S  1  ORY  )  : 

Example:  (3  2  1),  (lode:  (REVERSE  (I  1ST  T  ?  3)) 


Figure  b.  Selecting  the  menu  operation  "EVALUATE  something". 

Notice  that  the  code  (LIST  l  z  3)  that  produced  the  argument  to  REVERSE  appears  in 
the  code  portion.  When  we  used  the  list  as  a  component  of  a  larger  expression,  the 
code  which  produced  that  list  is  carried  along  as  part  of  the  code  for  the  larger 
expression.  We  can  build  up  large  expressions  a  little  bit  at  a  time,  and  Tinker 
makes  visible  all  the  intermediate  steps  of  the  evaluation,  so  we  can  verify  that  each 
step  had  the  effect  we  intended. 
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In  this  way,  Tinker  allows  us  to  build  up  parts  of  a  program  like  pieces  of  a  jigsaw 
puzzle We're  free  to  piece  together  small  parts  of  a  program  in  any  order,  then 
combine  them  into  larger  chunks.  The  order  in  which  we  evaluate  expressions  while 
constructing  the  program  doesn't  have  to  be  the  same  as  the  order  in  which  the  final 
program  will  evaluate  expressions.  We  can  write  the  program  in  the  left-to-right 
order  as  we  would  write  it  conventionally,  or  we  can  follow  the  bottom-up  order  of 
evaluation.  We  believe  this  added  flexibility  will  make  it  much  easier  to 
incrementally  construct  and  modify  programs. 


4.  Defining  a  new  function  using  an  example 

We  will  now  demonstrate  how  to  tell  Tinker  about  a  new  function.  Tinker  will 
learn  about  a  new  function  by  watching  us  work  out  an  example  of  a  typical  use  of 
the  new  function.  We  will  show  Tinker  how  to  perform  each  step  of  the  definition 
of  the  function.  Tinker  will  remember  each  step,  showing  us  the  result  of  each  step 
on  the  data  we  supplied  it  in  the  example.  When  we've  finished  working  out  the 
example,  Tinker  will  generalize  that  example  and  construct  a  procedure  for  the 
general  case. 
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We  will  start  with  a  very  simple  example,  so  the  reader  can  get  the  flavor  of  our 
approach,  and  we  will  then  proceed  to  more  complex  examples.  We  will  now  define 
a  function  2ND  which  extracts  the  second  element  of  a  list  using  the  operations  car 
and  CDR. 

To  begin,  we  pretend  we  already  have  the  definition  of  the  function  2ND,  and  we 
show  Tinker  a  sample  of  how  we  would  like  the  procedure  to  be  used.  We  feed  it 
the  list  (FIRST  SECOND  THIRD),  and  we  would  like  it  to  evaluate  to  SECOND. 

We  use  TYPEIN,  but  DON'T  EVAL  to  enter  the  code  (2ND  ‘(FIRST  SECOND  THIRD))  then 
use  new  example  for  function,  to  identify  this  as  a  new  example  for  the  function 
2nd. 


Definimi  (HISTORY): 

Cod cT  (  ? NO  Touorf  (TiR ST  SI  CONiTTh I R D )  )  ) 


[Type  some  rode: 

(2ND  ‘(FIRST  SECOND  THIRD)) 


Eri  ♦  t  nr  I J »  nr J*  y 


Figure  6.  Selecting  the  menu  operation  "NEW  EXAMPLE  for  function". 
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The  label  of  the  snapshot  window  informs  us  that  we  are  now  defining  what  the 
code  ( 2ND  '(first  SECOMD  THIRD))  should  evaluate  to.  Tinker  has  saved  the  state  of 
the  snapshot  window.  Inside  the  snapshot  window,  we  see  that  Tinker  manufactured 
a  new  variable,  which  it  called  2ND-ARG-1,  to  represent  the  single  argument  to  the 
procedure  2ND.  (We  could,  if  we  like,  rename  the  variable.)  Tinker  tells  us  that  the 
list  (first  second  third)  is  an  example  of  the  argument  to  the  function  2ND.  Given 
the  arguments  as  raw  material,  we  compute  the  value  of  the  procedure  in  the 
snapshot  window. 

Defining  (2ND  (QUOTE  (FIRST  SECOND  THIRD))): 

_  Txnmpl  cT  (  r  I R ST  SECOND  THIRD)  ,  Cod cT  2ND -ARC- i 

Code:  ( CDR ) 

♦ 


Figure  7.  Selecting  the  menu  operation  "CALL  a  FUNCTION". 
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To  extract  the  second  element  of  the  list,  we  must  first  chop  off  the  first  element 
using  the  function  CDR.  We  perform  the  menu  operations  CALL  a  function,  type  in 
CDR,  Fill  in  an  ARGUMENT,  then  EVALUATE  somothing.  After  these  three  operations, 
we’re  shown  that  the  CDR  of  the  argument  to  2ND  is  the  list  (SECOND  THIRD). 

Dcfininy  (2ND  (QU Oil  (t IRS1  SLCOND  IHIRD))): 

"irsi  SI  CON  »  1HIRD),  (Totle:  2ND- AUG  -  1 
Example:  (SECOND  IHIRD),  Code:  (COR  2ND-ARG- 1  ) 


Figure  S.  Selecting  the  menu  operation  “EVALUATE  something". 

Now,  we’re  getting  closer.  We  can  see  that  the  symbol  SECOND  is  the  first  element  of 
that  list,  and  we  can  obtain  it  by  taking  the  CAR.  Tinker  shows  us  that  the  answer 
we  want,  SECOND,  is  obtained  by  taking  first  the  CDR,  then  the  CAR  of  the  argument 
to  2ND. 
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Next  argument  to  (CAR)? 

Ex.im pTcTTrTitsi'  sIconiTt h i r F)~ co’eTe  -  " ? nT-arcTH 
V  (Example:  (SI  CO  NO  1IIIRD),  Code:  (COR  ?ND-ARO-jj) 

;  Code:  (CAR)  *  U 


f't’.uro  <).  OHi'i tmr>  the  menu  operation  "Fill  in  an  ARGUMENT". 

Although  this  function  is  really  simple,  it  illustrates  an  important  point  about  Tinker. 
In  conventional  programming,  extracting  elements  of  a  list  with  cars  and  CDRs  is 
usually  an  error-prone  process.  It's  very  easy  to  specify  one  operation  too  few  or 
too  many.  This  is  because  when  we  specify  a  path  through  a  data  structure,  we 
have  to  imagine  where  the  path  will  lead.  Since  Tinker  shows  us  all  the 
intermediate  results  when  the  path  is  specified,  the  immediate  visual  feedback  makes 
it  easy  to  verify  that  a  sequence  of  operations  has  the  desired  result 
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Since  we’ve  now  obtained  our  desired  result  lor  the  function,  we  select  the  RETURN  a 
value  operation,  saying  we  want  to  return  SECOND  as  the  result  of  (2ND  '(FIRST 
SECOND  THIRD)), 


Return  winch  one? 


Figure  10.  Selecting  the  menu  operation  "RETURN  a  value". 
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Tinker  restores  the  state  of  the  snapshot  window,  returning  us  to  HISTORY.  In  the 
editor  window,  we  examine  the  definition  of  2ND.  This  shows  us  that  Tinker  has 
written  the  code  for  2ND,  defining  it  as  a  function  of  one  argument 

l)ef  in  ini)  (HlSiORY) : 

F  xnmp  ip:  st  CONI) ,  Code  :  (2ND  (  QUO  r  L  ( I  I  RSI  SLCONO  D IIRD  )  )  ) 


(GRIN DIF  2ND) 

«m:njN  2ND  und-akg-d 

•  CAR  tf  Dll  IND-.MUi-D)) 


T 


r  •  f  I  *  r  M  •  r  i*  •(,* 


Figure  1  i.  Selecting  the  menu  operation  "RETURN  a  value". 

The  output  produced  by  Tinker  is  a  ordinary  Lisp  program,  indistinguishable  from  a 
definition  typed  in  using  the  more  conventional  methodology.  When  we're  writing  a 
program,  Tinker  maintains  its  own  data  representation  for  programs,  and  has  its  own 
evaluator,  so  it  can  provide  services  the  ordinary  Lisp  system  does  not  provide.  But 
since  Tinker  also  writes  ordinary  Lisp  code,  functions  produced  by  Tinker  can  be 
compiled  with  the  Lisp  compiler.  This  means  there's  no  penalty  for  using  Tinker 
during  program  development.  The  resulting  code  runs  just  as  efficiently  as  if  it  were 
written  conventionally. 
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Notice  that  .is  soon  as  our  procedure  appears,  we  are  guaranteed  that  it  works  for 
the  test  case  we've  given  it!  There’s  no  separation  between  writing  a  program  and 
testing  it.  Instead,  both  writing  and  testing  are  interleaved  and  performed 
incrementally. 

Tinker's  approach  is  more  robust  than  conventional  systems.  When  a  piece  of 
erroneous  code  is  introduced  in  a  conventional  program,  it  is  usually  buried  deep 
within  many  other  operations  before  we  get  a  chance  to  see  whether  the  code  ha. 
the  desired  result  for  typical  test  cases.  The  symptoms  appear  only  when  the  entire 
program  is  tested,  and  an  error  message  or  incorrect  result  is  produced.  We  are 
then  faced  with  the  arduous  task  of  isolating  the  erroneous  code  from  many  other 
operations,  most  of  which  are  irrelevant.  With  Tinker,  we  can  see  that  an  incorrect 
piece  of  code  fails  to  work  for  a  test  case  as  soon  as  it  is  introduced  to  the  system. 

5.  Defining  a  function  with  conditionals  and  recursion 

Now  that  we've  shown  how  to  define  a  simple  function  with  Tinker,  we  will  proceed 
to  a  more  realistic  scenario.  This  will  show  how  to  introduce  functions  with 
conditionals  and  recursion. 

A  folk  wisdom  among  programmers  says  that  in  order  to  thoroughly  test  a  program, 
at  least  one  example  for  each  branch  of  a  conditional  must  be  tried.  So,  to  define  a 
program  with  a  conditional,  we  must  provide  Tinker  with  several  examples,  each  one 
illustrating  an  important  path  for  the  resulting  prograta 

We  will  also  use  a  set  of  examples  to  build  up  functions  with  recursive  calls.  At  any 
time,  the  examples  we've  given  so  far  for  a  function  will  generate  a  partial  definition 
of  that  function.  It  may  not  completely  define  the  function  we  want,  but  the  partial 
definition  wilt  work  for  the  examples  given  it  so  far.  We  can  then  extend  the 
1  unction's  behaviour  with  new  examples  which  enable  it  to  handle  new  cases,  building 
upon  the  partial  definition. 

Our  demonstration  will  show  defining  a  symbolic  differentiation  function.  The 
function  will  accept  a  list  representing  a  symbolic  expression  in  prefix  form,  and 
return  the  symbolic  derivative  in  the  same  form.  The  DERIVATIVE  function  will  have 
several  cases,  based  on  the  type  of  the  expression,  and  may  need  to  recursively 
compute  the  derivative  of  a  subexpression. 
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First,  let's  tell  Tinker  about  a  very  simple  case.  The  derivative  of  a  variable  is  1 
with  respect  to  itself.  For  this,  we  give  Tinker  the  example  (DERIVATIVE  'X  *X). 


Del  i  n  i  IH|  (HIMOPV): _ 

Code:  ^DERIVATIVE  (QUO If  X)  (QUOII  X)) 


[ 


Figure?  12.  Selecting  the  menu  operation  "NEW  EXAMPLE  for  function". 


We  type  in  the  constant  1  using  TYPEIN  and  EVAl,  and  return  it  with  RETURN  a  value. 


Iicfinimj  (OlltlVAIIVI  (QUOII  X)  (QUOIf  X)): 
Example:  X,  Code:  Dl  Rl  VA I  IVI -AHG- 1 
Example:  X,  Code:  1)1  R! VA1  I VI  -AHG-? 
Example:  1,  Code:  1 


I  i;  nit-  i  i  '>••!*  (  Imj;  Hu-  uii'iwi  opcr.tlioii  "IthlllltN  ti  vnltMi". 
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Next,  we  present  a  more  complicated  example.  Let’s  try  the  derivative  of  the 
expression  (♦  X  :»).  This  example  leads  to  considering  two  more  cases:  we  shall  tell 
1  inku  how  to  take  the  derivative  of  an  exptession  which  is  it  sum,  atul  also  how  to 
lake  the  tin  lvalue  of  a  constant. 


Dr  Inti  ni  |  ( ll  I I  ol’V  ) : 

Ixnmplo:  I.  Code:  (  I'll*  I VA »  I VI  (Qtltlll  X)  (t)IIOll  X)) 
Code:  (IHIMVAIIVI  (QUO  It  (+  X  1))  (QUO  1 1  X)) 


Figure  14.  Select. ng  the  menu  operation  "NEW  EXAMPLE  for  function". 

The  recursive  rule  for  finding  the  derivative  of  a  sum  says  that  the  derivative  of  a 
sum  is  the  sum  of  the  derivatives  of  the  subexpressions.  We  extract  the 
subexpressions  x  and  3  from  the  sutn  (♦  X  3).  Tinker  remembers  that  X  is  the 
second  element  of  the  first  argument  to  DERIVATIVE,  and  that  3  is  the  third  element. 
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Dot  i  II  i  111)  (DIRIVAIIV!  (Olid  I  I  (+  X  !))  (  QUO  1 1  X)): 

Ixomplr:  (+  X  1),  Code:  PIP!  VA  I  1  VI  -APG-  1 
I x ample:  X,  Code:  01  R  I  VA  1  I  VI  -AIM;-  ? 
Example:  X,  (.‘ode:  (  CA  PI?  f'(  PIVAf  IV(  -  AP(»  -  1  ) 
Example:  3 ,  Code:  (CAKUR  DIR  I  VA  M  VI -ARG- 1  ) 


fipine  lb.  SeltHpn;’  the  menu  operation  "EVALUATE  something". 


Now,  we  have  to  take  the  derivative  of  X,  so  we  CALL  a  function,  type  DERIVATIVE, 
and  feed  it  the  subexpression  X  as  an  argument  Since  taking  the  derivative  of  a 
variable  is  something  Tinker  already  knows  how  to  do,  we  simply  evaluate  it, 
returning  the  answer  1. 


Defining  (DERIVATIVE  (QUOTE  (+  X  3))  (QUOTE  X)): 


Example :  (+  X  3),  Code:  DERIVATIVE-ARG- 
Example:  X,  Code:  DERIVATIVE-ARG-Z 
Example:  3,  Code:  ( CADDR  DERIVATIVE-ARG-1 ) 

Example:  1,  Code:  (DERIVATIVE  (CADR  DERIVATIVE-ARG-1 )  DERIVATIVE -ARC- 2 ) 


Firure  16  St  h'c  tin,?  the  menu  operation  "EVALUATE  something" 
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N»nv,  wo  try  the  same  thing  with  the  other  subexpression,  3  But  wait  --  linker 
doesn't  know  how  to  take  the  derivative  of  a  constant  like  3  yet.  So,  we  have  to  tell 
it.  Instead  of  evaluating  the  call  (DERIVATIVE  3  *X),  we  select  NEW  EXAMPLE  for 
function,  telling  Tinker  we  wish  to  define  this  case. 


I  x  <t  III  f*  I  < 


PH  ini  mi  (nnm'Aiivi  ('.moil  (+  x  :t))  ('?»»<)  n  x)): 

I  y. amp  I  e  :  (  +  X  3)  ,  (•<  id  r  :  PI  If  I  VA  I  i  VI  -AR(»-  I 
I  xaitip  It:  X,  Code:  IU  P.  I  VA  I  I  VI  -  Alt  (i  -  ? 

I  i.ale:  (  111  P  I  VA  t  I  VI  (OAliP  (H  It  I  VA  I  I  VI  -  APtJ- I  )  111  P  I  VA  I  I  VI  AIM 
I  .,||(  (  III  IM  V/  I  I  VI  I  I'pnill  x  ) ) 


Figure  17.  Selecting  the  menu  operation  "NEW  EXAMPLE  for  function". 

We  leave  temporarily  the  process  of  defining  the  derivative  of  (+  X  3)  to  define  the 
derivative  of  3.  This  shows  a  kind  of  top  down  program  development  process.  In  the 
course  of  developing  our  DERIVATIVE  procedure  by  stepwise  refinement,  we  discovered 
a  new  case  that  had  to  be  handled.  We  can  produce  a  definition  of  that  new  case, 
then  return  to  the  caller  to  continue  with  the  original  definition.  This  would  also  be 
useful  if  we  discovered  that  it  would  be  helpful  to  have  an  auxiliary  function.  We 
could  define  the  auxiliary  function,  make  sure  it  works  in  the  cases  needed  by  its 
caller,  then  return  to  continue  the  definition  of  the  caller. 

We  would  like  Tinker  to  support  a  top  down  debugging  methodology.  What  tempts 
most  practical  programmers  to  a  bottom  up  programming  style  rather  than  the 
conceptually  cleaner  top  down  programming  style  advocated  by  experts?  To  a  great 
extent,  it  is  the  fact  that  debugging  is  usually  performed  bottom  up.  Subprocedures 
arc  tested  before  the  calling  procedures  can  be  debugged.  One  well-known  way  to 
encourage  top  down  debugging  is  the  use  of  dummy  subprocedures.  To  test  a  calling 
procedure,  a  partial  definition  of  the  subprocedure  is  constructed,  which  need  only  be 
sufficient  to  test  the  cases  used  by  the  calling  procedure. 
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Tinker  makes  top  down  debugging  very  convenient  When  we  decide  we  would  like 
to  use  a  subprocedure  we  haven't  written  yet,  we  write  the  call  to  it,  and  define  it 
using  the  new  EXAMPLE  operation,  just  having  it  return  the  answer  for  a  specific  case 
rather  than  compute  the  value  in  general.  This  allows  us  to  test  the  calling 
procedure.  Later,  when  we  are  ready  to  write  the  definition  of  the  subprocedure,  we 
already  have  a  set  of  appropriate  test  cases  to  guide  us  in  writing  the  definitioa 

Now,  we  type  in  8  as  the  answer  for  the  derivative  of  the  constant  3,  and  select 
RETURN  a  value. 


Oof  tiling  (IMRIVA1IVF  t  ( QUO  IT  K )  ): 

I  xamp 1 c :  3  ,  Code :  "nFRI  VA 1 I  Vf -ARC- 1 
l xnmp I e :  X,  Code:  01 R1 VA1 1 V I -ARG-? 
Example:  d ,  Code:  0 


Figure  18.  Selecting  the  menu  operation  "RETURN  a  value". 

This  gives  Tinker  two  examples  for  the  DERIVATIVE  function, 

(DERIVATIVE  ’X  ’X)  evaluates  to  1 
(DERIVATIVE  3  'X)  evaluates  to  8 

Tinker  compotes  the  code  for  the  twro  cases,  and  notices  that  they’re  different  So 
Tinker  decides  that  the  code  for  the  DERIVATIVE  function  must  contain  a  conditional 
But  how  should  the  two  cases  be  distinguished? 
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Tinker  asks  us  to  distinguish  between  the  two  cases  by  defining  a  predicate  for  the 
conditional.  When  defining  a  predicate,  Tinker  displays  two  snapshot  windows.  One 
will  correspond  to  the  true  case  of  the  conditional,  one  to  the  false  case. 

_ _ Tjruc  predicate  for:  ixninple:  I,  Code:  1 

Example:  X  ,  Cod  e  :  1)1  R I VA  I  I VI  -ARG-1 
Example:  X,  Code:  01 R1 VAT  I VI -ARG-? 


False  predicate  for:  Ixamplc:  0,  Code:  0 
Example:  3 ,  Code:  Dl  l!  1  VA  11 VI  -ARG-I 
Example:  X,  Code:  Of R I VAT  I  VC -ARC- ? 


Type  tmnrlliing  to  evaluate: 

0 

How  do  I  distiiigitisli  hrtwren 
"Example:  1.  Code:  1"  and 
"Example:  ft.  Code:  ft"?| 

Ed i  ter  WmtJou' 


figure  19.  Selecting  the  menu  operation  "RETURN  a  value”. 

As  we  define  the  predicate,  code  will  appear  simultaneously  in  both  windows.  Since 
the  values  of  the  arguments  to  DERIVATIVE  are  different  in  the  two  cases,  the  code 
for  the  predicate  may  evaluate  differently  in  one  window  than  the  other.  Hopefully, 
if  we've  successfully  defined  a  predicate  to  distinguish  between  the  two  cases,  the 
predicate  will  evaluate  to  T  (Lisp's  way  of  saying  true)  in  the  top  window,  and  NIL 
(Lisp's  false)  in  the  other. 
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How  do  we  decide  how  to  choose  between  the  two  cases?  In  the  first  case,  the 
distinguishing  property  is  that  the  two  arguments  to  DERIVATIVE  are  equal.  So,  we 
enter  the  code  (EQUAL  DERIVATIVE-ARG-1  DERIVATIVE-ARG-2 ),  and  see  that  it  evaluates 
to  T  in  the  top  window,  NIL  in  the  bottom  window.  We  return  this  as  the  value  of 
the  predicate. 

True  predicate  for:  Example:  1,  Code:  1 
Example:  X,  Code:  DERIVATIVE -ARG-1 
Example:  X,  Code:  DERIVATIVE-ARG-2 
Example:  T,  Code:  (EQUAL  OERIVATIVE-ARG-I  DERIVATIVE-ARG-2) 


false  predicate  for:  Example:  0,  Code:  0 

Exn|n|J,C;  3j  Coc|c.  DERIVATIVE -ARG-1  ~ 

Example:  X,  Code:  DERIVATI VE -ARG-2 
Example:  NIL,  Code:  (EQUAL  DERIVATIVE -ARG-1  DERIVATIVE -ARG-2 ) 


Figure  20.  Selecting  the  menu  operation  "RETURN  a  value". 

Tinker’s  displaying  both  cases  of  a  conditional  is  valuable  in  that  it  helps  to  assure 
that  the  predicate  performs  its  desired  function  of  separating  the  two  cases.  Often, 
the  distinguishing  predicate  is  more  easily  determined  after  the  code  for  the  cases 
appears.  Conditionals  can  also  be  introduced  explicitly  in  a  more  conventional 
manner  with  the  Make  a  CONDITIONAL  menu  operation.  We  would  also  like  to  provide 
the  option  of  leaving  one  branch  of  the  conditional  undefined  while  the  code  for  the 
other  branch  is  worked  out. 
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Tinker  returns  to  the  case  of  defining  the  derivative  of  the  sum,  (+  X  3)  We 
examine  the  code  for  the  DERIVATIVE  function  that  Tinker's  built  up  so  far.  We  can 
see  that  the  code  consists  of  an  if  with  the  predicate  and  the  two  cases  wc'vc 
defined. 


Defining  (DERIVATIVE  (QUOTE  (+  X  3))  (QUOTE  X)): 


Example:  1, 
Example:  0, 


Example:  (+  X  3),  Code:  DERIVATIVE -ARG-1 
Example:  X,  Code:  DERIVATIVE-ARG-Z 
Code:  (DERIVATIVE  (CADR  DERIVATIVE -ARG-1 )  DERIVATIVE-ARG-Z ) 
Code:  (DERIVATIVE  (CADDR  DERIVATIVE-ARG-1 )  DERIVATIVE-ARG-Z) 


DFF  UN  1)1  HIVATIVi;  MW  UIYAI IVI  -AIUl-1  1)1  III YAH V1.-AKC.-2) 

nr  u:qu.m,  m  im  ativi.-arc-i  ih;iuyati\t-ai«;-2) 


i 

«uS 


[f.  j  I  t'  "  Mir.  t  V 

Figure  21.  Selecting  the  menu  operation  "RETURN  a  value". 


At  this  stage,  Tinker  thinks  that  in  every  case  where  the  arguments  to  DERIVATIVE 
aren’t  equal,  the  answer  is  zero.  This  isn't  correct,  of  course,  but  it  constitutes  a 
partial  definition,  correct  for  what  we've  shown  it  so  far,  and  we  will  continue  to 
extend  the  definition. 
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We've  computed  the  derivatives  of  the  subexpressions,  now  it's  time  to  combine  them 
to  form  the  derivative  of  the  sum.  Since  the  derivative  of  a  sum  is  the  sum  of  the 
derivatives,  we  construct  a  list  of  the  symbol  ♦  and  the  expressions  for  the 
derivatives  of  the  subexpressions.  Evaluating  this  results  in  the  list  (♦  1  8). 

Pel  ini  nq  (PlltlVAIIVI  (OUOII  (+  X  ;t))  (OUOII  X)): 

Ixnmplr:  (+  X  3 )  ,  Code:  PI  PI  VA  I  1  VI  -ARC-  1 
fXcimple:  X,  Code:  Id  It  IVAI  I VI -AIHJ-? 

Ix.imple:  (+1  ...),  Code:  (MSI  ( OUO 1 1  +)  ...) 


I  1 1 * 1 1 1  •  *  ‘ <  Imc.  P»’  menu  operation  "EVALUATE  something”. 

(We  won’t  bother  living  to  simplify  the  expression  for  the  derivative,  so  that  it  could 
recognize  that  (+  1  0)  is  the  same  as  1.)  Since  this  is  the  correct  answer  for  the 
derivative  of  (•*■  x  3),  we  return  it 
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This  provides  Tinker  with  yet  another  case  for  the  DERIVATIVE  function.  Again,  it 

shows  us  two  snapshot  windows  and  asks  us  to  define  a  predicate,  contrasting  the 

sum  with  the  last  case  we  showed  it,  (DERIVATIVE  3  'X).  We  enter  the  code  (ATOM 

DERIVATIVE-ARG-I )  to  distinguish  the  constant  case  and  return  it  Now,  Tinker  can 

differentiate  constants,  variables  and  sums. 

Irur  pr  ed  irate  lor:  Ixnmple:  II,  Code:  II 

I  nip  I  c  :  I,  Code:  PI  R 1  VAT  I VI  -AUG-  I 

lx, ample:  X,  Code:  1)1  It  I VA I  I VI  -AP.G-  ? 

Ixnmple:  1,  Code:  (AIOM  PI  III  VA II VI  -AUG- 1 ) 


False  prod  i  (.ale  for:  Ixnmple:  (  +  I  .  ..),  Code:  (MSI  ( QUO  1 1  +) 
I  xamp  I  e  :  (+  X  ;i).  Code:  PI  R  I  VA  I  I VI  -ARC-  1 
Ixnmple:  X.  Code:  1)1  It  I  VAT  1  VI  -ARC-  ? 

Ixnmple:  fill,  Code:  (AIOM  PI'R  I  VA  f!  VI -AP«- 1  ) 


Figure  23.  Selecting  the  menu  operation  "RETURN  a  value". 

Tinker  currently  treats  multi-way  branches  or  dispatches  as  nested  two-way  branches. 
It  is  possible  to  modify  it  to  produce  a  dispatch  directly. 
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To  round  out  our  DERIVATIVE  program,  we  could  add  another  case  telling  Tinker 
how  to  do  products ,  using  the  chain  rule. 

Do f  ini nt|  (IIISIORY) : 

Ixamplo:  1  ,  God  o  :  (  HI  l»  I VA I  I VI  ((.moil  X)  (QUO  If  X)) 
Example:  (+  1  (I).  Cmle:  (IURIVAMVI  ((.moil  (+  X  '!))  ((JUOII  X)) 
Code:  (III  Ml  VAN  VI  ( QUO  1 1  (*  X  X))  (  QUO  II  X)) 


L 


Figure  2a.  Selecting  the  menu  operation  "NEW  EXAMPLE  for  function". 


Del  in  inf)  (l)IRIVAIJVI  (QU01E  (*  X  X))  (QUO  1 1  X)): 
f  xnmp  1  e  :  (  *_X  X  j ,  Code :  1)1  R  t  VA  1 1 VL  -ARG- 1 
Example:  X,  Code:  1)1  RIVAHVf -ARG-Z 
Example:  (+  (♦  X  ...)  ...),  Code:  (l 1ST  (QUOTE  +)  . ..) 


Figure  25.  Selecting  the  menu  operation  "RETURN  a  value". 
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True*  protl  i<  .it  e  lot:  Multiple:  1,  Code:  (  HI  I*  I  VA  I  I  VI  (CAPP.  IM  P  I  VA  I  I  VI  -AIM;- I  )  . 

Maniple.  (+  X  .1 )  ,  Code:  PI  l<  I  VA  I  I  VI  -AIM;-  I 
I  x.nnp  I  o  :  X,  Codr  ,  PI  IM  VA  I  I  VI  -AP(«-  2 
Maniple:  I,  Codr:  (iniiAl  (CAP  PI  IM  VAIIVI  -ARC- I  )  (QtlOII  •)) 


False  predicate  for:  I  x.nnp  I  c :  (♦  X  .  ..),  Code;  (MSI  ( QUO  1 1  ♦)  ) 

I  xnmp  I  e  :  (♦  X  X),  Code:  PI  IM  VA  I  I VI  -ARC,- I 
I  X.imp  lo:  X,  Codr:  PI  IM  VA  I  I  VI  -ARG-  2 
txnmple:  MU.  Codr:  (IQUA!  (  CAP  PI  IM  VA  I  I  VI  -ARC-  1  )  ( QUO  I  I  -*  )  ) 


Figure  26.  Selecting  the  menu  operation  "RETURN  a  value". 

And,  if  we’re  really  going  to  be  conscientious  about  our  derivative  program,  we 
should  also  define  a  case  where  we  can’t  take  the  derivative!  (Programmers  often 
neglect  to  include  negative  examples  as  well  as  positive  ones  when  testing  a  program. 
This  is  a  prime  cause  of  the  fragility  of  many  current  software  systems.)  We 
illustrate  a  case  where  our  DERIVATIVE  function  should  produce  an  error  message. 


_  Pel  iitimj  ( 1 1 1 S I  OR  V ) : 

lx, ample:  1,  Code:  (DIIMVAIIVI  ( QUO  1 1  X)  (QU01I  X)) 

Example:  (+  |  o),  Code:  ( 111  R I  VA!  I VI  (QUOII  (+  x  :i))  (QUOII  xn 
Example:  (+  (•  x  1)  (*  1  X)),  Code:  ( 01 R I  VA  I  I VI  ( QUO  1 1  (♦  X  X))  (<.PKi||  x)) 

Code:  (DIRIVAUVI  (QUOIl  (UNKNOWN))) 


Figure  27.  Selecting  the  menu  operation  "NEW  EXAMPLE  for  function". 
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Pot  i  n  i  in)  ( m  i>  l  va  1 1  vi  (‘.moil  (uuntjovu) )  (imoii  k)). 

I  x.imp  1  r  :  ( UNKHOV/tJ ) ,  Code:  HI  l>  1  VA  11  VI  -ARC-  1 
I  X.Hiip  I  (  :  X,  Code:  HI  Rl  VA  I  I  VI  -ARC- 2 
Ix.implr:  "You  pooled!",  (‘.otic:  (I’I’IIJI  "You  pooled1") 


f  ij’ure  28.  Selecting  the  menu  operation  "EVALUATE  something". 

True  |ii  relic, tt  o  lor:  lx. imp  It:  (+(♦>:...)  .),  Cade:  (IIM  (nthill  <  ) 

I  Xiimp  I  o  :  (♦  X  X).  Code:  PI  III  VA  I  1VI  -ARC- I 
IXflinplr:  X,  Code:  HI  R  I  VA  I  I  VI  -ARC- 2 
I  xomp  I  <■ :  I,  Code:  ( 1  QUAl  (CAR  PI  R  I  VA  I  I  VI  -AUG-  1  )  (0(1011  ♦)) 


[ft  Iso  |)i'nli(,|tr  I  or  ;  I  .x»uii|)  I  o  ;  "You  fj  *  »c>  f  «  j|  i  "  .  Codr:  (PRIfJI  "You  ponied!") 

i  x.imp  i <  ;  (urji nnvrj) .  code  ,  pi  rivaiivi -aro- i 
Ix.implr:  X,  Code:  PI  R  I  VA  I  I VI -ARC,- ? 

I  X  cliiip  I  r  :  fJII  ,  Codr  :  (K'UAI  (CAR  PI  R  I  VA  I  I  VI -ARC- I  )  (  Olio  I  (  ♦)) 


Figure  29.  Selecting  the  menu  operation  "RETURN  a  value" 
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IK  I  i  it  i  i it |  (IIIMOI'.Y)  : 

Example:  I,  Code;  (DtRIVAMVl  (QUO 1 1  X)  (0110 1 1  X )  ) 

IXiimplr:  (+  I  (I),  Code:  (IMIMVATIVt  (QUOI!  (+  K  3))  ( 0<'(>  1 1  X)) 
Example:  (+  (♦  X  I)  (♦  I  X)),  Code:  ( III  I*  1 VA I  I VI  ( QUO  I  I  (♦  X  X))  (QHulf  X 
Ixnrnplr:  "You  tjooled!",  r..dc:  ( IH  P  I  VA  I  I  VI  (QUOI!  ( lirjIMOVlJ )  )  (QUnif  x)) 


Figure  30.  Selecting  the  menu  operation  "RETURN  a  value*. 


Collecting  all  these  cases  results  in  the  following  final  program: 

(DEFUN  DERIVATIVE  ( DERIVATIVE-ARG-1  DERIVATIVE-ARG-2) 

(IF  (EQUAL  DERIVATIVE-ARG-1  DERIVATIVE-ARG-Z)  1 
(IF  (ATOM  DERIVATIVE-ARG-1)  0 

(IF  (EQUAL  (CAR  DERIVATIVE-ARG-1)  '♦) 

(LIST  '♦ 

(DERIVATIVE  (CADR  DERIVATIVE-ARG-1) 
DERIVATIVE-ARG-Z) 

(DERIVATIVE  (CADDR  DERIVATIVE-ARG-1) 
DERIVATIVE-ARG-Z)) 

(IF  (EQUAL  (CAR  DERIVATIVE-ARG-1)  '*) 

(LIST  '♦ 

(LIST  ’* 

(CADR  DERIVATIVE-ARG- I ) 

(DERIVATIVE  (CADDR  DERIVATIVE-ARG-1) 
DERIVATIVE-ARG-2)) 

(LIST  '* 

(DERIVATIVE  (CADR  DERIVATIVE-ARG-1) 
DERIVATIVE-ARG-Z) 

(CADDR  DERIVATIVE-ARG-1 ) ) ) 

(PRINT  "You  ooofed!")))))) 


Associating  examples  with  function  definitions  will  yield  important  benefits  during 
program  maintenance  as  well  as  program  constructioa  When  the  definition  of  a 
function  is  edited,  Tinker  can  run  through  all  the  test  cases  again,  automatically,  and 
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issue  a  warning  if  any  examples  work  out  differently  with  the  new  definition. 
Tinker  cati  make  sure  that  changes  intended  to  extend  the  behaviour  of  some 
function  don’t  have  the  effect  of  breaking  previously  correct  code. 


6.  Other  features  of  Tinker 


We  will  present  brief  explanations  of  other  features  of  Tinker  which  appear  on  the 
Tinker  edit  menu ,  but  weren't  encountered  in  the  above  scenario. 


Figure  [3 1 1 


_ Tinker  EDIT  menu _ 

CALL  a  function 
Fill  in  an  ARGUMENT 
EVALUATE  something 
NEW  EXAMPLE  for  function 
TVPEIN  and  EVAL 
vJTYPEIN,  but  DON’T  EVAL| 
"Mare  a  CONDITIONAL 
Edit  TEXT 
Edit  DEFINITION 
Step  BACK 
UNFOLD  something 
COPY  something 
DELETE  something 
Escape  to  LISP 
RETURN  a  value 


UNFOLD  is  a  kind  of  inverse  to  Fill  in  an  ARGUMENT.  It  takes  apart  expressions, 
removing  the  arguments  from  a  piece  of  code.  COPY  duplicates  an  expression  in  the 
snapshot  window.  DELETE  simply  removes  an  expression  from  the  snapshot  window. 

Edit  DEFINITION  is  the  operation  for  modifying  definitions  of  functions.  It  chooses  a 
specific  example  for  a  function  defined  with  Tinker,  and  returns  to  a  snapshot 
window  defining  that  example.  Commands  can  be  used  to  edit  the  definition  which 
appears  in  the  window,  and  the  definition  of  the  function  is  suitably  changed.  We 
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would  like  to  have  Tinker  run  through  all  the  examples  again  to  check  to  see  if  they 
have  changed  as  a  result  of  the  edit 

Step  BACK  is  a  debugging  tooL  Since  Tinker  always  remembers  the  code  that 
produced  every  value  which  appears  on  the  screen,  the  Tinker  interpreter  is 
completely  reversible!  (Normally,  the  expense  of  remembering  everything  might  be 
prohibitive,  but  this  is  only  done  for  functions  being  debugged  with  Tinker.  After  a 
function  is  completed,  it  is  compiled,  and  the  overhead  disappears.) 

When  a  bug  is  encountered,  we  can  simply  step  backwards  until  the  offending 
expression  is  found.  Since  we  select  which  expression  to  examine  from  the  menu,  it's 
easy  to  skip  over  details  of  the  evaluation  of  expressions  which  are  irrelevant  to  the 
bug.  We  can  zoom  in  on  bugs  by  examining  evaluations  at  progressively  finer  levels 
of  detail.  This  is  unlike  conventional  steppers  which  always  step  linearly  forward  or 
breakpoints  and  stack  debuggers  which  always  step  backward  and  lose  information 
about  evaluated  arguments. 

We  also  provide  operations  which  fall  back  on  the  more  conventional  programming 
tools,  so  that  these  can  also  be  used  in  the  cases  where  they’re  appropriate.  Edit 
TEXT  takes  the  Lisp  code  representation  for  an  item  in  the  snapshot  window,  and  lets 
us  edit  it  with  the  Zwei  text  editor.  When  we're  finished  editing  the  text,  we  can 
indicate  an  expression  in  the  editor  and  return  it  to  Tinker  to  replace  the  originally 
selected  item.  Sometimes  it's  easier  to  fix  things  by  typing  than  by  menu  selection. 

Escape  to  LISP  puts  us  in  an  ordinary  Lisp  READ-EVAL-PRINT  loop  in  the  editor 
window.  Any  Lisp  expression  can  be  evaluated  there,  and  the  result  is  printed  back 
into  the  editor  window.  And,  as  we  have  seen,  any  typed  Lisp  expression  can  be 
included  in  Tinker's  snapshot  window  using  the  TYPE  IN  and  EVAL  operation.  T  hus 
Tinker  can  be  used  to  supplement  existing  facilities  rather  than  replace  them.  Tinker 
provides  compatible  interfaces  to  the  conventional  programming  system  which  make 
all  of  its  features  available  as  welL 


7.  Previous  w ork 

The  most  direct  ancestor  to  our  work  was  Smith's  Pygmalion,  which  pioneered  the 
idea  of  menu-oriented  programming.  Our  techniques  of  displaying  examples  and 
source  code  for  programs  simultaneously,  our  direct  production  of  Lisp  code,  our 
method  of  abstracting  conditionals,  and  the  use  of  a  set  of  test  cases  for  each 
function  are  some  of  the  contributions  which  distinguish  our  work  from  his.  Currys 
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system  is  similar  in  spirit  to  Pygmalion,  and  both  these  systems  made  interesting  use 
ot  graphical  rather  than  textual  representations  of  programs,  which  we  have  not 
explored  Biermann  has  an  interesting  system  which  applies  automatic  programming 
techniques  to  synthesizing  programs  from  demonstrations  using  examples.  We  see  this 
as  a  fruitful  area  for  further  research,  and  we  intend  to  experiment  with  hooking  up 
I  inker  to  the  description  system  Omega  of  Attardi,  Simi  and  Hewitt  to  perform 
reasoning  about  the  structure  of  programs.  Tinker  might  be  useful  as  a  basis  for  a 
user  interface  to  program  understanding  systems  such  as  that  of  Rich,  Shrobe,  and 
Waters.  While  we  are  interested  in  incrementally  interleaving  program  construction 
with  testing ,  they  have  explored  interleaving  program  construction  with  verification 
Ultimately,  we  would  like  to  integrate  all  of  these. 
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